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The  purpose  of  this  paper  is  to  assess  the  strategic  impacts  of  unit  procured 
Information  Technology  (IT)  in  support  of  Battle  Command  (BC)  and  assess  the  Army 
major  acquisition  programs  ability  to  support  urgent  warfighter  needs.  Today's  selection 
and  use  of  BC  systems  is  a  highly  competitive  process  and  extremely  leader  centric. 
Unit  commanders  and  their  staff,  outside  of  the  Army's  acquisition  process,  expend  unit 
funds  to  purchase  or  create  BC  systems  that  meet  their  specialize  approach  to  BC. 
Training  and  information  is  not  available  to  commanders  that  describe  the  impacts  of 
pursuing  their  own  BC  solutions  to  meet  individual  preferences.  Army  acquisition 
programs  are  at  a  competitive  disadvantage  in  meeting  urgent  warfighter  needs  and 
therefore  users  circumvent  the  system  rather  than  use  it.  The  result  is  duplicative  and 
inconsistent  unit  solutions  that  reduce  the  effectiveness  of  BC  and  the  efficiency  of 
resources.  Unity  of  effort  is  needed  to  balance  warfighter  innovation,  manage  the 
impact  of  these  innovations,  and  the  ability  to  incorporate  successful  innovations  into 
army  acquisition  programs  for  long  term  sustainment. 


INEFFICIENT  BATTLE  COMMAND  RESULTS  FROM  UNIQUE  COMMANDERS 

SOLUTIONS 


Our  ability  to  leverage  the  power  of  information  will  be  key  to  our  success 
in  the  21st  Century. 

—  Honorable  John  G.  Grimes 
ASD(NII)/DoD  CIO 

Introduction 

The  DoD  Net-Centricity  initiatives  and  Army  2007  Posture  Statement  are  based  on 
the  premise  that  effective  use  of  information  technology  will  lead  to  a  military  dominant 
force.  The  DoD  Net-Centricity  objective  is  to  provide  Joint  commanders  with  a  globally 
networked  environment  (interconnecting  infrastructure,  systems,  processes,  and 
people)  within  which  data  is  shared  seamlessly  and  in  a  timely  manner  among  users, 
applications,  and  platforms  enabling  rapid  decision  superiority,  resulting  in  full  spectrum 
dominance.  The  2007  Army  Posture  Statement  specifies  that  by  leveraging 
technologies,  and  the  power  of  the  Network,  “soldiers  and  commanders  will  enjoy  far 
greater  ability  to  see  and  to  act  first  -  ahead  of  their  adversaries  -  while  dealing  with  the 
full  spectrum  of  challenges  they  will  face.”1 

The  change  in  the  strategic  environment  resulting  from  the  terrorist  attacks  in  2001 
has  significantly  re-scoped  Army  modernization  efforts.  By  2003,  with  our  Nation 
conducting  operations  in  both  Afghanistan  and  Iraq  there  was  a  need  to  provide  a 
consistent  set  of  BC  solutions  across  the  force  to  enable  timely  sharing  of  BC 
information.  As  such,  the  Chief  of  Staff  of  the  Army  provided  guidance  in  August  2003  to 
build  the  'Good  Enough'  Army  Battle  Command  Systems  (ABCS)  and  field  it  to  the 
active  force.  This  version  was  designated  as  ABCS  6.4. 


Today,  ABCS  is  trained  and  fielded  to  units  deploying  to  operations  in  Iraq  and 
Afghanistan.  Regardless  of  theater  its  use  is  limited.  The  bulk  of  BC  is  being 
conducted  using  a  variety  of  unit  procured  non  standard  emerging  systems.  Often  these 
systems  are  sought  after  and  purchased  to  meet  a  commander’s  perceived  need  that  is 
either  1 )  not  offered  by  the  ABCS  systems,  2)  the  warfighter  is  unaware  of  the  capability 
in  ABCS,  or  3)  he  wants  a  specific  visualization  that  is  not  offered  by  ABCS.  The  impact 
of  this  non  standardization  is  an  inability  of  units  to  synchronize  an  approach  to 
Doctrine,  Organizations,  Training,  Materiel,  Leadership  and  Education,  Personnel  and 
Facilities  (DOTMLPF)  across  the  area  of  operations. 

The  intent  of  this  SRP  to  provide  a  background  on  ABCS  and  the  effects  of  unit 
employment  of  non  standard  solutions  in  use  in  Iraq  from  2005  to  the  present  day;  to 
provide  an  analysis  of  what  drives  units  to  procure  their  own  systems;  and  the  resulting 
strategic  impacts  of  the  unique  solutions  across  DOTMLPF.  It  will  also  take  a  critical 
look  at  the  Army  acquisition  process  and  its  constraints  on  programs  of  record  resulting 
in  the  systems  inability  to  be  competitive  in  the  development  of  BC.  It  will  then  describe 
several  initiatives  that  have  focused  on  resolving  issues  associated  with  the  proliferation 
of  software  in  the  CENTCOM  AOR.  Finally  it  will  offer  specific  recommendations  that 
would  balance  BC  standardization  with  commander’s  specific  preferences  with  the  goal 
of  achieving  the  Net-Centric  and  Army  Posture  Statement  premise  of  military 
dominance. 

Background 

FM  3.0  defines  BC  as  "the  exercise  of  command  in  operations  against  a  hostile, 
thinking  enemy."2  Leadership  and  decision  making  are  central  to  the  Battle  Command 
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concept.  Effective  battle  command  demands  superior  decisions — more  timely  and  more 
effective  -  than  those  of  the  enemy.3  In  exercising  Battle  Command,  "the  commander 
combines  the  art  and  science  of  warfare  in  thinking  and  action:  the  science  deals  with 
facts  and  processes  based  on  principles  derived  from  the  physical  world — this  is  where 
the  network  is  most  useful;  the  art  emphasizes  using  intuitive  faculties  that  are  acquired 
from  education,  training,  experience  and  personal  observation."4 

In  1995,  the  Army  published  its  first  Army  Digitization  Master  Plan  (ADMP)  that 
introduced  the  concept  of  “Digitizing  the  Battlefield”  through  the  use  of  information 
technology  to  provide  the  warfighters  a  horizontally  and  vertically  integrated  digital 
information  network  that  supports  warfighting  systems  and  assures  C2  decision-cycle 
superiority.5  Program  Executive  Officer  Command,  Control,  and  Communications 
Tactical  (PEO  C3T),  began  working  with  the  Training  and  Doctrine  Command 
(TRADOC)  to  develop  the  science  of  BC  through  the  development  of  the  ABCS.  Early 
on  these  efforts  were  focused  on  developing  the  First  Digital  Division  (4th  Infantry 
Division  at  Fort  Hood,  TX)  and  conducting  a  series  of  experiments. 

Experimentation  continued  for  many  years.  As  of  2001 ,  the  Army  Modernization 
Plan  described  the  strategic  environment  of,  “...  the  United  States  could  enjoy  a  period 
of  relative  strategic  calm  in  which  no  single  foreign  power  could  threaten  our  vital 
interests  with  conventional  military  forces.”6  Although  the  plan  did  describe  threats  to 
include  “terrorist  networks”  the  environment  did  not  ignite  an  urgent  need  to  meet  the 
digitization  goals  across  the  force.  With  technology  becoming  more  prevalent,  units 
outside  the  experimentation  process  began  to  seek  their  own  BC  solutions.  The  units 
that  were  provided  Army  program  of  record  (POR)  solutions  became  known  as  the 
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"Have's"  while  the  rest  of  the  Army  was  the  "Have  Not's".  The  limited  scope  of  the  Army 
digitization  efforts  lead  to  a  commercial  market  place  for  BC  solutions,  and  established 
the  mode  of  operation  for  units  to  expend  their  own  funds  to  procure  them.7 

With  the  terrorist  attacks  on  September  11,  2001,  the  Strategic  environment 
significantly  changed  and  deploying  units  struggled  to  pull  together  the  partially  fielded 
ABCS  systems.  These  units  purchased  information  technology  solutions  to  meet  their 
BC  requirements.  In  August  2002,  the  82d  Airborne  Division  deployed  to  Afghanistan 
and  stood  up  Coalition  Task  Force  -  82  (CTF82).  At  this  time,  CTF82  was  only  partially 
fielded  with  ABCS  and  selected  to  use  Maneuver  Control  System-Light  (MCS-L)  to 
support  the  execution  of  BC.  MCS-L  at  this  time  was  an  ABCS  system  under 
development,  but  was  authorized  for  limited  use  under  the  ‘beta’  program.  MCS-L 
interoperability  was  limited  and  units  in  the  Joint  Operational  Area  (JOA)  did  not  have 
position  location  systems,  so  most  data  viewed  on  MCS-L  was  manually  entered.8 
Although  MCS-L  provided  CTF82  with  shared  visualization  that  supported  execution  of 
current  operations,  their  intelligence  staff  was  unable  to  provide  timely  answers  to 
priority  information  requirements  (PIR).  Further  analysis  of  the  situation  identified  the 
cause:  data  was  being  collected  using  multiple  intelligence  software  packages  across 
numerous  systems  resulting  in  islands  of  data  sources  without  sufficient  tools  to 
integrate  them.  As  a  result,  the  unit  initiated  efforts  using  Web  technology  and  a  central 
database  to  build  the  capability  they  needed.  Eventually  this  capability  would  be  known 
as  FusionNet.9 

In  early  2002,  in  preparing  for  Operation  Iraqi  Freedom  (OIF)  the  Force  XXI  battle 
command-brigade  and  below  (FBCB2)  system  was  augmented  with  satellite 
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communications  and  installed  on  key  vehicles  of  the  3rd  Infantry  Division  (ID),  82d 
Airborne  Division,  the  Marine  Expeditionary  Force  (MEF)  and  in  British  tank  forces.  The 
capability  became  known  as  Blue  Force  Tracking  (BFT).10  BFT  was  successful  at 
providing  friendly  unit  situational  awareness,  becoming  a  critical  enabler  for 
commanders  that  used  this  information  to  ‘decide  rapidly  where,  when,  and  how  they 
would  employ’11  the  ground  forces  engaged  in  the  conflict. 

BFT  provides  only  a  small  part  of  BC,  and  although  it  was  a  great  success,  the 

rest  of  BC  (across  forces  engaged  in  the  first  phase  of  OIF)  was  composed  of  a  partial 

fielding  of  ABCS,  to  include  the  MCS-L  (again  still  in  Beta)  at  Army  Divisions,  and 

Command  and  Control  Personal  Computer  (C2PC)  at  Corps  and  the  MEF.  OIF 

assessments  identified  some  success  with  individual  ABCS  systems,  but  identified 

significant  shortfalls  in  ABCS,  in  that  the  systems  failed  to  interoperate  in  the  manner 

expected,  and  did  not  adequately  provide  the  commander  relevant  information.  12 

In  2003,  the  Chief  of  Staff  of  the  Army  (CSA)  directed  that  the  Army  shift 
its  funding  efforts  from  developing  the  BC  architecture  from  the  bottom-up 
to  one  that  was  focused  on  developing  the  architecture  from  the  top-down. 
Additionally,  he  directed  fielding  the  capability  to  the  entire  Army.  Prior  to 
this  decision,  the  entire  Army  Battle  Command  suite  was  only 
programmed  for  a  fraction  of  the  Army  force.  This  decision  redirected 
resources,  stopped  development  of  the  ABCS  software  suite  at  the  current 
Block  IV,  and  redirected  all  available  funding  to  fielding  a  C2  system  to  the 
entire  force  structure.13 

Based  on  the  CSA  direction,  PEO  C3T’s  top  priority  was  to  expedite  the  delivery  of 
ABCS  6.4  software.  The  CSA  wanted  a  “Good  Enough”  system  that  focused  on  the 
commander’s  operational  needs,  plus  Joint  and  Coalition  Interoperability  to  be  delivered 
across  the  force.  Today,  ABCS  6.4  meets  the  Army’s  “good  enough”  prioritized 
requirements  and  provides  net-centric  data  management  to  support  interoperability 
between  its  systems.  However,  ABCS  6.4  will  need  further  development  to  interoperate 
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with  joint  and  coalition  forces.  Currently,  units  deploying  in  support  of  Operation 
Enduring  Freedom  (OEF)  and  OIF  are  equipped  and  trained  on  ABCS  6.4. 14 

Today,  in  OIF,  ABCS  capabilities  are  used,  “but  the  integrating  aspects  of  ABCS 
have  been  marginalized.” 15  This  is  due  to  the  nature  of  the  operations  being  less 
focused  on  conventional  combat  operational  tasks  of  “fire  and  maneuver”  and  “move, 
shoot  and  communicate”  16  that  ABCS  was  designed  for.  Instead  the  focus  is  on 
collaboration,  non-standard  interactions  (CID,  WIT,  CA,  PSYOPS,  etc.),  combined 
operations  with  Iraqi  &  multi-national  forces  and  specific  information  management 
processes.  As  a  result,  units  use  a  combination  of  Microsoft  Office  products,  portals, 
and  emerging  systems  (CIDNE,  FusionNet,  TIGR,  TACTICOMP,  Effects  Based  tools, 
etc.)  to  meet  the  majority  of  their  BC  requirements. 17 

Discussion 

Over  the  last  several  years  deployed  units  have  used  the  operational  needs 
statement  (ONS)  process  to  obtain  supplemental  dollars  in  order  to  build  emerging 
systems.  With  predictions  that  the  supplemental  budget  is  soon  to  dry  up  we  need  to 
address  the  need  for  these  systems.  The  discussion  will  focus  on  answers  to  the  follow 
three  questions:  (1 )  Why  do  commanders  build  their  own  systems?  (2)  Why  don’t  the 
Program  of  Record  systems  provide  the  units  what  they  need?  (3)  What  has  been  done 
to  mitigate  the  situation  and  how  effective  was  it?  When  addressing  these  questions,  I’ll 
use  significant  event  (SIGACT)  tracking  systems  as  a  case  study. 

Why  Do  Commanders  Build  Their  Own  Systems? 

Software  is  different  from  other  capabilities  provided  to  warfighters.  Warfighters 
don't  discard  their  vehicles,  uniforms,  or  weapons  and  just  go  build  or  purchase  another. 
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But  this  is  exactly  what  they  do  with  Battle  Command  software.  If  they  need  something, 
they  build  or  procure  it  and  load  it  on  their  computers  without  considering  potential 
impacts.  I  propose  there  are  several  reasons  for  this. 

First  historically,  the  "have  not"  units’,  as  discussed  in  the  background,  only 
alternative  was  to  procure  their  own  BC  systems.  A  strategic  impact  of  the  Department 
of  Army's  decision  to  limit  fielding  to  experimental  divisions  for  over  a  decade  was  that  it 
established  the  mode  of  operation  for  units  to  believe  they  needed  to  fend  for 
themselves.  Next,  software  is  cheap  and  easy  to  build,  and  changing  software  is 
standard  operation  for  anyone  with  a  PC.  If  you  need  something,  search  the  internet, 
download  free  trials,  pick  the  best  and  then  purchase  and  install.  Another  reason  comes 
from  the  'Art'  of  BC.  Commanders  want  to  visualize  data  in  the  way  that  makes  sense  to 
them.  Often  POR  applications  cannot  be  tailored  to  meet  individual  visualization 
preferences.  As  the  owner  of  the  system,  you  can  continue  to  change  software  to  meet 
new  requirements,  and  therefore  more  rapidly  meet  the  commander  and  his  staff 
emerging  change  requests.  For  SIGACT  tracking  systems,  units  have  conducted  a 
Relief  in  Place/Transfer  of  Authority  (RIP/TOA)  and  impacted  the  transition  of  the 
SIGACT  tracking  system  by  replacing  it  with  their  own.  This  is  what  I  consider  the  "Not 
invented  here"  reason.  All  these  stem  from  there  being  a  need  that  is  not  being  met! 
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Figure  1  -  OIF  Event  Reporting  -  May2006 
Using  the  SIGACT  Case  Study,  figure  1  shows  the  various  systems  that  were 

individually  built  by  units  to  manage  events.  The  various  systems  utilized  tracked 

different  attributes  for  events,  and  manual  re-entry  was  used  to  translate  and  move  data 

between  systems.  PowerPoint  storyboards  were  used  to  describe  the  event  through  the 

use  of  pictures,  maps  and  words.  PowerPoint  provided  an  unconstrained  and  effective 

way  to  quickly  share  knowledge  about  the  event.  The  figure  portrays  various  systems 

that  took  part  in  collecting  the  event  data  during  the  tactical  response.  Not  shown  in  the 

figure  is  the  impact  of  this  event  data  on  operational  and  strategic  processes.  For 

example,  as  documented  by  the  Joint  Improvised  Explosive  Device  Defeat  Organization 

(JIEDDO),  an  I  ED  event  reported  at  the  tactical  level  is  essential  to  support  operational 

and  strategic  processes  such  as:  Forensic  analysis,  IED  defeat  mechanisms,  Device 

fabrication,  trends  and  patterns  by  geographic  area,  RF  signatures  and  force  protection 

requirements  and  bomb  maker  and  his  affiliated  network.  18 
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The  most  significant  outcome  of  units  procuring  their  own  equipment  is  that  it 
impacts  the  effectiveness  of  BC  and  the  efficiency  of  resources.  In  particular,  there  are 
inefficient  costs  associated  with  duplication  or  overlapping  capabilities.  The  secondary 
effects  include  the  inability  to  standardize  across  the  force,  inhibiting  the  development  of 
standardize  doctrine,  training  and  SOPs,  and  duplicative  efforts  for  security 
accreditation,  testing,  maintenance,  interoperability,  logistics  and  sustainment  for  these 
products. 

The  impact  of  these  systems  on  our  ability  to  meet  the  net-centric  knowledge 
sharing  goals  will  be  analyzed  in  order  to  examine  the  impacts  of  unit  procured  solutions 
to  the  effectiveness  of  BC.  The  Net-Centric  Operational  Environment  Joint  Integrating 
Concept  (NCOE  JIC)  specifies  that  data  is  the  facts,  information  is  data  in  context,  and 
knowledge  is  the  intrinsic  value  of  the  information.  19  It  further  defines  knowledge 
sharing  as: 

The  ability  of  networked  users  to  manage  and  make  available  relevant, 
accurate  information,  transform  it  into  knowledge,  and  act  upon  it  with 
confidence.  This  provides  access  to  newly  discovered  or  recurring 
information  in  a  useable  format  and  facilitates  collaboration,  distributed 
decision-making,  adaptive  organizations,  and  a  greater  unity  of  effort  via 
synchronization  and  integration  of  force  elements  to  the  lowest  levels.20 

These  individual  unit  solutions  inhibit  sharing  of  data,  information  and  knowledge. 
As  a  result  there  is  less  effective  unity  of  effort  in  the  integration  of  force  elements  to  the 
lowest  levels.  One  approach  that  is  often  used  to  overcome  this  shortfall  is  to  keep 
various  systems  in  place,  but  create  data  strategy  that  enables  interoperability  between 
these  systems.  Interoperability  provides  a  means  of  sharing  the  facts,  but  does  not 
enable  the  context  or  the  intrinsic  value  of  the  fact  to  be  shared.  The  November  2007 
the  PEO  C3T  BC  observations  from  Iraq  identified  that  “Interoperability  does  not 
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achieve  collaboration;  data  is  removed  from  its  context  and  is  subject  to  various 
interpretations”21.  Additionally,  their  observations  indicate  that  the  current  BC  emphasis 
to  support  operations  in  Iraq  is  collaboration.  Thus,  a  unit  commander’s  unique  solution, 
even  when  interoperability  may  appear  to  support  his  unit’s  effectiveness,  may  actually 
reduce  overall  effectiveness  across  the  operation. 

The  use  of  PowerPoint  to  develop  storyboards  is  a  way  that  a  unit  may  collaborate 
on  a  given  event.  The  result  is  ‘unit  acquired  knowledge’  without  the  ability  to  extract 
data  so  that  it  can  be  used  by  automated  processes  to  analyze  the  event.  This  is 
knowledge  without  usable  data,  thus  limiting  its  usefulness  outside  the  unit. 

Going  back  to  our  example,  since  the  I  ED  reported  event  data  collected  at  the 
tactical  level  is  critical  to  a  wide  variety  of  processes  it  is  imperative  that  the  data  be 
consistent,  complete  and  accessible.  Unique  unit  solutions  at  the  tactical  level  lessen 
the  effectiveness  of  the  rest  of  the  process. 

Why  Don’t  The  Program  Of  Record  (POR)  Systems  Provide  The  Units  What  They 
Need? 

Among  the  Army’s  biggest  challenges  today  are  acquisition  activities.  The 
combination  of  the  need  for  the  Army  to  be  prepared  for  are  more  ambiguous  and 
diverse  threat,  the  fast  pace  of  technology,  the  changing  environment  outpacing  the 
developing  concepts  and  doctrine,  the  high  pace  of  operations  and  need  to  continuously 
evolve  software  in  support,  the  transformation  of  the  Army  and  the  larger  DoD  initiatives 
to  move  to  a  Joint  Net-Centric  warfighting  force  all  contribute  to  the  challenge.  22  Given 
these  competing  interests,  the  Army  instituted  Software  Blocking  (SWB)  in  2001,  with 
the  "overall  goal  from  a  System  of  Systems  viewpoint  to  field  a  group  of  proven  mutually 
interoperable  systems  which  best  support  the  Army  Warfighter,  IAW  TRADOC- 
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established  priorities."  23  POR  system  offices  are  currently  challenged  in  providing 
timely  solutions  to  urgent  requests  that  come  from  OIF/OEF.  The  software  blocking 
process  is  designed  to  be  flexible  enough  to  accommodate  the  warfighter’s  urgent 
needs,  while  assessing  operational  impact,  value  added,  training  impact  and  risk.  The 
processes  ensure  adequate  testing  in  order  to  evaluate  the  capability  and  reduce  risk. 

While  ABCS  systems  focus  on  implementing  the  Good  Enough  solution,  they 
adhere  to  the  SWB  process.  ABCS  6.4  “Good  Enough”  was  built  based  on  requirements 
primarily  resulting  from  unit  experience  during  the  conventional  combat  operations 
phase  of  the  second  gulf  war  in  2003.  These  requirements,  known  as  the  7+1, 
prioritized  implementation  of  interoperability  in  order  to  provide  the  common  operational 
picture  (COP)  essential  to  having  shared  situational  awareness,  and  the  capability  to 
exchange  necessary  information  across  echelons  and  functional  areas  during 
operations.  24  With  a  COP,  ABCS  could  then  “automate  combat  business  processes 
during  the  prosecution  of  well  known  and  rehearsed  staff  battle  drills.”25  ABCS  utilized 
current  technology  innovations  during  development,  and  then  stagnated  for  a  year  and 
a  half  while  system  of  system  testing  was  being  conducted. 

During  ABCS  6.4,  testing  conducted  on  warfighter  requirements  transitioned  from 
the  conventional  combat  operations  based  on  7+1  to  irregular  warfare  requirements. 
“This  coincided  with  a  significant  increase  in  relevant  technology  maturity  predominantly 
in  the  web  services  area  as  well  as  network  availability  to  the  warfighter.  The  increase  in 
requirements,  as  well  as  technology  innovations  enabled  the  unit  (and  others)  to  create 
responsive  technology.”26  When  ABCS  6.4  was  approved  for  release  operators  found  it 
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well  suited  for  supporting  short  and  decisive  conventional  combat  operations,  but  far 
less  capable  of  supporting  the  current  irregular  warfare  mission. 

In  order  to  get  back  on  track,  ABCS  shifted  its  priority  from  periodic  major  updates 
to  short-term  and  low  risk  iterative  updates  based  on  user  urgent  needs.  The  Army  uses 
the  Operational  Needs  Statement  (ONS)  processes  to  “identify  urgent  operational 
needs  that  jeopardize  soldiers’  lives  or  mission  accomplishment.”27  Using  this  process 
ABCS  systems  have  shortfalls  identified  and  updates  approved  for  implementation. 
However,  prior  to  fielding  updates  based  on  ONS,  ABCS  is  required  to  go  through  the 
SWB  process.  Within  the  last  year,  the  SWB  process  was  updated  to  attempt  to 
incorporate  a  quarterly  schedule  for  approvals  and  submission  of  patches  in  order  to  be 
responsive  to  urgent  warfighter  needs.  To  date,  the  approval  part  of  the  process 
significantly  lags  the  implementation  and  testing,  resulting  in  units  finding  alternative 
methods  to  get  the  capability  they  need.  28 

CJCS  Guidance  for  2007-2008  (1  OCT  07)  charges  us  all  to  “improve 
requirements,  acquisition,  and  technology  development  efforts  to  ensure  rapid, 
predictable  delivery  of  needed  combat  capabilities  to  our  warfighters.” 29  LTC  Mike 
Gibler’s  (former  SBCT  BN  commander)  perspective  on  the  current  process  is  that  it  is 
an  “arduous  acquisition  process  -  the  enemy  in  the  future  fight... needs  to  meet 
requirements  of  the  warfighter  instead  of  the  system”30. 

The  SWB  process,  given  a  combination  of  tiered  risk  decision  authority  and  the 
quarterly  certification  for  release,  should  ensure  rapid,  predictable  delivery  of  warfighter 
capabilities.  It  is  “personalities,  relationships  and  priorities”31  that  are  slowing  it  down. 
Often  patches  are  held  up  in  ‘bureaucratic  exercising  of  oversight  that  is  bogged  down 
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in  a  protracted  coordination  process  that  gives  excessive  attention  to  detail’32  and  the 
elimination  of  risk.  What  is  needed  is  a  ‘shared  commitment  -  often  the  most  obvious 
determinant  of  success’  33  -  to  meet  the  warfighter  need  as  quickly  as  possible. 
Additionally,  flexibility  and  innovative  approaches  are  needed  to  validate  software  so  (in 
accordance  with  its  risk  level  and  urgency)  it  can  be  fielded  to  fulfill  the  pending  need.  34 

“Change  propagates  faster  today  than  any  other  period.”35  As  a  result,  PORs  need 
a  fair  playing  field  in  order  to  effectively  meet  warfighter  demands.  The  SWB  process 
enforces  different  rules  for  PORs  and  non-POR  systems;  it  requires  validation  in  a  test 
facility  that  does  not  control  many  of  the  interfaces,  and  ultimately  results  in  less  control 
of  system  usage  as  warfighters  circumvent  the  process  rather  than  use  it.36 

AR  70-1  states  that  “All  milestone  decision  authorities  (MDAs)  will  provide  a 
software  blocking  assessment  that  will  be  submitted  for  validation....”37  It  does  not 
identify  a  process  for  systems  without  MDA  (or  non-Program  of  Record  systems).  As  a 
result,  non-POR  programs  are  given  a  competitive  advantage  in  that  they  can 
implement  and  deploy  software  changes  at  the  unit’s  discretion.  The  unit  takes  the  risk 
of  the  software  change  not  working,  the  training  implication,  the  impacting  of 
interoperability  or  causing  other  havoc.  Most  units  are  willing  to  accept  this  risk  because 
it  can  be  controlled  by  limiting  the  scope  of  the  patch,  or  simply  reloading  the  old  version 
if  the  new  version  fails.  The  alternative  of  working  with  a  POR  and  submitting  an  ONS, 
and  then  working  the  through  the  SWB  process  is  lengthy  and  time  consuming.38 
The  whole  concept  of  requiring  a  program  to  go  to  a  test  facility  to  certify  software  prior 
to  its  release  needs  to  be  re-assessed.  Today’s  environment  is  a  good  example; 
updates  to  PORs  depend  on  interfaces  with  programs  that  the  Army  does  not  own.  The 
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impact  is  that  by  the  time  the  test  facility  gets  what  it  needs  to  certify  a  system  the  non 
POR  interface  has  changed,  thus  invalidating  the  test.39  In  the  Net-Centric  future  we 
cannot  expect  to  test  systems  in  a  controlled  environment. 

As  a  result  of  ABCS  inability  to  meet  user  demands,  users  are  going  around  the 
POR  process  to  get  what  they  desire.  The  lack  of  POR  solution  impacts  both  the 
effectiveness  of  BC  and  the  efficiency  of  resources  discussed  in  the  previous  section. 


What  Has  Been  Done  To  Mitigate  The  Situation,  And  How  Effective  Was  It? 

The  Department  of  Army  and  CENTCOM  have  had  several  efforts  focused  on 
controlling  the  incorporation  of  unit  procured  solutions  in  the  CENTCOM  AOR.  The  goal 
of  these  efforts  as  outlined  by  CENTCOM’s  “Introduction  of  New  IT  Into  the  CENTCOM 
AOR”  policy  is  intended  to: 

(a)  Improve  theater  joint  interoperability  by  ensuring  all  new  capabilities 
service  the  broader  joint  mission  vice  unit  or  organization-centric 
requirements;  (b)  Stem  the  introduction  of  duplicative  or  overlapping 
capabilities  competing  to  satisfy  common  requirements  while  consuming 
network  capacity;  (c)  Enhance  information  assurance  by  addressing 
security  certification  prior  to  fielding;  (d)  Incorporate  a  NETOPS 
management  construct  for  the  system  prior  to  IOC;  (e)  and  ensure  its 
capabilities  have  an  out-year  sustainment  strategy.  40 

In  order  to  discuss  this  fully,  a  summary  of  the  Army  Best  of  Breed,  PEO  C3T 
Battle  Command  Common  Services  (BCCS)  and  Information  Management  Framework 
(IMF),  transition  of  science  and  technology  initiatives  into  program  of  records,  and  the 
CENTCOM  Introduction  of  New  IT  Into  the  CENTCOM  AOR  follow. 


Army  Best  of  Breed 

HQDA  initiated  a  Best  of  Breed  (BoB)  process  in  October  2005  in  order  to  reduce 
the  number  of  commercial  and  government  developed  products  being  used  in  the 
tactical  environment.  “The  Army’s  goal  was  to  mitigate  the  proliferation  of  unit 
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purchased  and  non-standard  Knowledge  Management  (KM)/collaboration  tools  and 
applications  across  the  Army.  During  this  four  month  effort  the  G-3/5/7  and  the  CIO/G-6 
worked  with  Corps  and  TRADOC  schools  to  identify  and  assess  currently  deployed 
tools  to  support  standardization  on  a  single  KM/Collaboration  solution  set.”  41  The  result 
was  a  reduction  in  the  systems  from  25  tools  to  6  that  represented  the  "Best  of  Breed” 
technologies  across  three  KM  categories. 

This  process  was  effective  in  that  it  engaged  HQDA,  FORSCOM,  and  the  PEOs  in 
collecting  and  assessing  capabilities  and  tools  that  are  being  procured  in  theater.  The 
selection  of  multiple  tools  in  the  three  areas,  however,  limited  the  effect  of  having  a 
common,  interoperable  and  integrated  solution  as  a  result  of  this  process.  For  example, 
the  two  tools  selected  for  the  Data  Fusion  (SIGACT)  category  were  FusionNet  and 
CIDNE.  Each  tool  was  developed  at  MNC-I  by  rotating  CORPS.  The  result  of  selecting 
both  is  that  as  a  CORPS  rotates  they  can  change  the  established  Data  Fusion  tool.  This 
change  impacts  all  subordinate  unit  processes,  and  requires  data  to  be  translated  and 
imported  into  the  incoming  tools  database. 

With  respect  to  this  decision,  CENTCOM  J3  Command  and  Control  Division 
conducted  a  Joint  Information  Management  Board  (JIMB)  in  February  2007  to  develop  a 
plan  to  migrate  to  a  single  authoritative  SIGACT  reporting  /  analysis  tool.  The  result  of 
this  conference  was  the  immediate  selection  of  CIDNE  for  Iraq,  and  the  migration  to 
CIDNE  in  Afghanistan  linked  to  the  next  unit  JTF  rotation.  Additionally,  CENTCOM  J3 
documented  architectural  and  information  exchange  requirements,  database  roles, 
responsibilities,  authorities,  oversight  and  training  requirements  for  the  centralized, 
authoritative  theater  SIGACTs  /  IED  reporting  database.  Furthermore,  CENTCOM  J3 
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began  discussions  on  a  transition  plan  to  migrate  the  capability  to  a  POR  for 
sustainment.  42 

Battle  Command  Common  Services  /  Information  Management  Framework 

In  order  to  more  effectively  support  the  warfighter  in  OIF/OEF,  PEO  C3T  has 

established  an  approach  that  would  balance  a  unit’s  ability  to  innovate  solutions  that 
could  be  shared  with  others  as  well  as  be  incorporated  into  ABCS  for  long  term 
resourcing.  These  efforts  include  Battle  Command  Common  Services  (BCCS),  which 
provide  a  common  hardware  and  software  solution  to  Divisions  and  BCTs  in  order  to 
enforce  a  common  implementation  of  Microsoft  Enterprise  services  such  as  email, 
portal,  web  and  security  practices,  and  to  provide  ABCS  interoperability  services. 
Additionally,  PEO  C3T  established  the  Information  Management  Framework  (IMF) 
shown  in  figure  2.  This  framework  enables  a  common  approach  for  the  development  of 
unit  solutions  so  they  can  be  shared,  supported  and  sustained  in  a  common  way. 
Additionally,  associated  processes  have  been  established  to  enable  warfighters  to 
submit  their  software  solutions  for  validation,  certification  and  incorporation  into  the 
library  of  capabilities  made  available  across  the  force.  The  IMF  is  made  up  of  three 
tiers:  the  first  tier  is  the  infrastructure  that  is  provided  by  BCCS,  the  next  tier  is  the 
automated  processes  (Web  Applications)  that  are  built  by  ABCS  and  users.  The  final 
tier  is  the  end  user  system  (Unit  Site).  PEO  C3T  recognized  that  most  processes 
(middle  tier)  are  common  among  units  but  their  employment  is  often  tailored  to  meet 
unit  specific  concept  of  operation  (CONOPS).  The  tiered  approach  enables  the  middle 
tier  processes  to  be  shared  and  then  customized  by  the  unit  when  added  to  the  unit  site 
so  that  it  supports  their  specific  CONOPS  and  visualization  preference.  The  initial  IMF 
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concept  was  developed  in  FY2005  and  since  has  been  implemented  by  PEO  C3T. 
Recently  the  IMF  concept  has  been  incorporated  into  an  overall  DA  CIO/G6  strategy  in 
support  of  the  DoD  Net  Centric  initiatives. 


PEO  C3T  Information  Management  Framework 


DA  CIO/G6  SOA  for  Tactical  Environment 


Figure  2:  PEO  C3T  IMF  and  DA  CIO/G6  Net  Centric  Initiative 


Transition  of  Science  and  Technology  Initiatives  into  Programs  of  Record 

Several  science  and  technology  (S&T)  programs  have  been  successfully  worked 

directly  into  combatant  command  capabilities  using  an  agile  approach  to  rapidly  build  an 
interim  capability  to  meet  the  emergent  warfighter  needs.  Once  military  utility  was 
successfully  demonstrated  these  programs  were  transitioned  to  PORs  for  sustainment, 
validation  and  fielding.  Examples  of  such  programs  include  DARPA’s  CPoF  and  the 
JCTD  NOMADD  43that  have  transitioned  to  ABCS.  Using  this  approach,  the  S&T 
community  worked  closely  with  CENTCOM,  including  forward  support  on  the  battlefield, 
in  order  to  exploit  future  advances  in  technology  and  iterate  and  mature  the  interim 
capabilities.  This  process  is  advantageous,  in  that  it  allows  the  maturing  and  evaluation 
of  the  utility  of  an  emerging  tool  prior  to  committing  it  to  acquisition. 

Often  the  S&T  community  provides  potential  solutions  that  were  not  design  for 
transition  to  a  POR.  Then  once  the  military  utility  is  successfully  identified  transition  may 
be  unfeasible  due  to  differences  in  user  experiences,  data  structures,  programming 
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languages,  software  design  or  required  infrastructure.  As  a  result  these  solutions  add  to 
the  proliferation  of  systems,  and  sustaining  them  becomes  costly  to  an  acquisition 
program.  Thus,  it  is  imperative  that  up  front  transition  is  planned  and  proper  oversight  is 
established  in  order  to  ensure  successful  transition. 

CENTCOM  Policy 

In  June  2007,  CENTCOM  established  the  “Introduction  of  New  IT  into  the 
CENTCOM  AOR ”  policy.  This  policy  established  procedures  for  “approval  over  the 
introduction  of  any  new  or  enhancements  or  expansions  to  existing  IT  capabilities  in  the 
USCENTCOM  AOR.  This  includes  networks,  systems,  applications,  ACTDS,  JCTDS, 
pilots,  beta  tests  and  prototypes  that  rely  on  the  theater's  joint  network  to  conduct  data 
exchanges.” 44  The  effectiveness  of  this  policy  is  personality  dependent  since  tools  are 
not  available  in  the  CENTCOM  AOR  to  monitor  changes  and  manage  software  on  the 
network.  Military  Services  are  responsible  for  organizing,  training,  and  equipping  units. 
Since  this  policy  gives  CENTCOM  the  authority  to  specify  what  equipment  can/can’t  be 
used  in  his  AOR,  IT  efforts  planned  for  CENTCOM  require  continuous  coordination  in 
order  to  be  successful. 

Effectiveness  of  Efforts 

All  efforts  described  in  this  section  are  supportive  in  controlling  of  the  proliferation 
of  BC  systems  in  CENTCOM.  However,  they  can  be  circumvented;  therefore  the 
effectiveness  is  dependent  on  commander’s  support  and  incorporation  of  these  controls 
across  DOTMLPF.  These  efforts  need  a  robust  lessons  learned  process  so  that  lessons 
are  incorporated  into  a  coherent,  focused,  long-term  approach  to  BC  modernization 
efforts  resulting  in  the  competitive  advantage  needed  for  irregular  warfare.  Clear 
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understanding  of  the  purpose  of  these  efforts  and  their  impact  to  the  effectiveness  and 
efficiency  of  BC  needs  to  be  communicated  to  commanders  to  affect  their  success. 

Recommendations 

Unity  of  Effort  -  It’s  a  Team  Sport 

The  current  threat  changes  our  environment  from  a  “time  of  reasonable 
predictability  -  to  an  era  of  surprise  and  uncertainty.”45  Program  Managers  are 
challenged  to  effectively  support  the  warfighter  in  this  environment.  They  need  agile  and 
adaptive  enterprise  approaches  that  are  supported  by  systems,  personalities  and 
relationships  focused  on  common  priorities  in  order  to  facilitate  timely  solutions  to 
emerging  warfighter  needs.  In  doing  so,  there  needs  to  be  a  balancing  of  the  risk 
associated  with  delivering  a  solution  with  the  benefit  to  the  warfighter  engaged  in 
conflict.  The  COCOM  and  warfighter  need  to  be  critical  players  in  the  decision  cycle, 
and  they  must  be  able  to  trust  the  acquisition  process  so  they  do  not  have  to  find 
alternative  ways  to  meet  their  needs.  Alignment  of  S&T  and  PORs  should  be 
established  to  allow  for  refinement  and  evaluation  of  an  emerging  warfighter  need 
before  committing  to  acquisition.  Management  and  oversight  of  the  S&T  efforts  and 
POR  could  ensure  effective  and  efficient  transition  of  successfully  demonstrated 
capabilities,  reduce  risk  and  cost  to  a  POR,  and  enable  continuous  development  of 
solutions  to  meet  emerging  needs.  The  solution  is  one  of  balance.  A  certain  amount  of 
independence  is  healthy  and  desirable  in  order  to  promote  innovation.  The 
implementation  process  needs  to  allow  units  and  the  S&T  community  the  ability  to 
innovate  and  methods  to  assess  the  solutions  for  incorporation  into  a  program  of  record 
in  order  to  provide  long  term  re-sourcing. 
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Net-Centricity  Leads  to  Less  Control 

As  systems  become  more  networked  the  less  control  there  will  be  of  the 
environment  that  they  will  operate.  Army  BC  systems  are  employed  in  joint,  interagency, 
and  multinational  environments.  As  such  information  technology  policies,  guidance  and 
directives  need  to  be  coordinated  with  Joint  services  and  with  combatant  commanders 
in  order  to  provide  fully  integrated  and  interoperable  networked  joint  information 
technology  solutions.  Our  software  release  process  and  associated  testing  needs  to  be 
tailored  to  take  into  account  the  uncertainty  of  the  environment  in  which  BC  systems  will 
be  employed.  As  such,  software  today  (and  ever  increasingly  as  we  achieve  net- 
centricity)  needs  the  opportunity  to  be  validated  without  the  requirement  to  bring  every 
interface  to  a  test  facility  for  approval.  New  risk  mitigation  approaches  and  test 
strategies  need  to  be  developed  to  prepare  for  this  future. 

Train  Capabilities  and  Big  Picture 

The  “future  cannot  be  won  by  focusing  on  technology;  they  will  be  won  by 
preparing  our  people...”46 

The  rate  of  technology  change  is  predicted  to  continue  to  escalate.  Since  we 
cannot  control  this  we  need  to  ensure  our  processes  can  account  for  its  continuous 
change.  Training  should  be  focused  on  applied  capabilities  verses  specific  systems. 
Additionally  commanders  require  an  understanding  of  the  larger  picture  that  a  given 
capability  supports  and  how,  given  the  highly  networked  environment,  a  single  unit 
solution  can  have  negative  effects  on  operational  and  strategic  level  processes. 
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Incorporate  Irregular  Warfare  Methods  across  DOTMLPF 

Our  enemy  today  is  agile  and  adaptive  and  he  uses  technology  to  his  advantage. 
Future  assessments  describe  an  emerging  national  security  era  dominated  by  irregular 
warfare.47  As  such,  the  Army  modernization  efforts  need  greater  attention  on 
incorporating  technology  innovations  developed  in  theater  into  a  coherent,  focused,  and 
long-term  approach  to  BC.  In  exercising  BC,  the  commander  combines  the  art  and 
science  of  warfare.  As  such,  it  is  not  enough  to  incorporate  only  the  technology 
developed  by  warfighter,  but  we  also  need  to  capture  and  integrate  them  across  the  rest 
of  the  DOTMLPF  domains. 

Conclusion 

Ms.  Helen  Greiner,  iRobot  Co-founder  and  Chairman,  stated  that  your  ‘success  is 
measured  by  having  long  term,  satisfied  partners  that  trust  you.’48  Given  the  proliferation 
of  unit  procured  information  technology  solutions  -  our  acquisition  programs  have  failed 
to  meet  this  measure  of  success.  This  proliferation  has  significant  implications  on  our 
ability  to  achieve  the  net-centric  objective  of  providing  Joint  commanders  with  a  globally 
networked  environment  within  which  data  is  shared  seamlessly  and  in  a  timely  manner 
among  users,  applications,  and  platforms,  enabling  rapid  decision  superiority  resulting 
in  full  spectrum  dominance.  49  The  current  DA  approach  is  not  advantageous  in 
enabling  program  of  record  BC  systems  to  be  agile  and  timely  enough  to  meet  pending 
operational  needs.  The  result  is  that  units  go  around  the  system,  procuring  their  own  BC 
capabilities,  reducing  the  overall  effectiveness  and  efficiency  of  the  mission.  On-going 
irregular  warfare  efforts  in  Iraq  and  Afghanistan  provide  the  Army  an  opportunity  to  work 
with  the  Joint  community  and  COCOMs  using  agile  and  adaptive  enterprise  processes 
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that  are  supported  by  personalities  and  relationships  focused  on  common  priorities  in 
order  to  facilitate  timely  solutions  to  emerging  warfighter  needs.  Taking  take  advantage 
of  this  necessitates  change!  Our  environment  is  uncertain  and  our  enemy  is  adaptive, 
therefore  to  defeat  him  we  must  be  as  well. 


Endnotes 

1  Francis  J.  Harvey  and  Peter  J.  Schoomaker,  A  Statement  On  The  Posture  of  The  United 
States  Army  2007,  Posture  Statement  presented  to  the  1 10th  Cong.,  1st  sess.  (Washington, 
D.C.:  U.S  Department  of  the  Army,  2007),  37. 

2  U.S.  Department  of  the  Army,  Operations,  Field  Manual  3-0  (Washington,  D.C.:  U.S. 
Department  of  the  Army,  14  June  2001),  5-1. 

3  U.S.  Department  of  the  Army,  Mission  Command:  Command  and  Control  of  Army  Forces, 
Field  Manual  6-0  (Washington,  D.C.:  U.S.  Department  of  the  Army,  August  2003),  4-24. 
Hereafter  referred  to  as  FM  6-0. 

4  LTG  William  S.  Wallace,  “Network-Enabled  Battle  Command,”  Military  Review  (May-June 
2005):  4. 

5  GEN  Gordon  R.  Sullivan  and  COL  James  M.  Dubik  ,  Army  Digitization  Master  Plan 
(Washington,  D.C.:  Department  of  the  Army,  1995)  available  from  http://www.globalsecurity.org/ 
military/library/report/1 995/admp95-adotoc.htm;  Internet;  accessed  20  January  2008. 

6  U.S.  Department  of  the  Army,  2001  Army  Modernization  Plan  (Washington,  D.C.:  Office  of 
the  Deputy  Chief  of  Staff  for  Programs,  2001 ),  5. 

7  Derived  from  personal  observation  as  the  Software  Architect  for  MCS-L  when  I  deployed 
to  support  CTF82  in  Afghanistan  in  Aug  2002  and  then  to  Kuwait  to  assist  101st  AASLT  and 
82ABN  establish  C2  prior  to  the  start  of  OIF  1  combat  operations. 


9  Ibid. 

10  Otto  J.  Guenther,  “Blue  Force  Tracking,”  Army,  April  2004,  13. 

11  David  M.  Moore,  Battle  Command  Software:  Meeting  the  Commander’s  Needs?  Strategy 
Research  Project  (Carlisle  Barracks:  U.S.  Army  War  College,  15  Mar  2006),  16. 

12  Ibid.,  16. 

13  COL  Harold  Greene  and  Robert  Mendoza,  "Lessons  Learned  From  Developing  The 
ABCS  6.4  Solution,"  Defense  Acquisition  Review  Journal  (Apr-Jul  2005):  196. 


22 


14  Ibid.,  197-198. 

15  John  Willison,  “Summary  Observations  from  OIF  &  OEF  Trip,”  briefing  slides,  Ft. 
Monmouth,  PEO  C3T,  28  November  2007. 

16  Andrew  F.  Krepinevich,  President  Center  for  Strategic  and  Budgetary  Assessments,  The 
Future  of  U.S.  Ground  Forces  Challenges  and  Requirements,  testimony,  before  U.S.  Congress, 
Senate,  Committee  on  Armed  Services,  17  April  2007,  19. 

17  Willison. 

18  LTC  Mark  Wickham,  United  Kingdom,  “Weapons  Technical  Intelligence  Process,”  briefing 
slides  with  scripted  commentary,  JIEDDO,  CENTCOM,  Forward  Headquarters,  Oatar,  5 
February  2007. 

19  U.S.  Joint  Chiefs  of  Staff,  Net-Centric  Operational  Environment  Joint  Integrating  Concept 
Version  1.0  (Washington,  D.C.:  U.S.  Joint  Chiefs  of  Staff,  31  October  2005),  14.  Hereafter 
referred  to  as  NCOE-JIC. 

20  Ibid.,  16. 

21  Willison. 

22  John  E.  Peters  et  al.,  A  Methodology  for  Developing  Army  Acquisition  Strategies  for  an 
Uncertain  Future  (Santa  Monica:  RAND,  2007),  28. 

23  Army  Software  Blocking,  available  from  http://www.tec.army.mil/ctis/software/ 
software_blocking/main.html;  Internet;  accessed  27  Jan  08. 

24  Carol  Wortman  and  Robert  Pitsko,  “Battle  Command  Path  Ahead,”  briefing  slides  with 
scripted  notes,  Redmond,  WA,  Microsoft  Army  Symposium,  8  February  2006,  6. 

25  Carol  Wortman  and  Robert  Pitsko,  “Information  Management  Framework  Information 
Paper,”  Ft.  Monmouth,  PEO  C3T,  November  2005,  3. 

26  Wortman,  8  February  2006,  6. 

27  U.S.  Department  of  the  Army,  Force  Development  Materiel  Requirements,  Army 
Regulation  71-9  (Washington,  D.C.:  U.S.  Department  of  the  Army,  30  April  1997),  11.  Hereafter 
referred  to  as  AR  71-9. 

28  COL  Harold  Greene,  Director  of  Material,  G8,  HODA,  interview  by  author,  10  February 
2008. 

29  Col  Jeffrey  Caton,  “Industry  Day:  Reset,  Reconstitute,  and  Revitalize  Our  Armed  Forces,” 
in  Joint  Processes  and  Landpower  Development:  Selected  Readings  (Carlisle  Barracks:  U.S. 
Army  War  College,  February  2008),  35. 

30  LTC  Mike  Gibler,  Army  War  College  Seminar  Discussion,  12  February  2008. 

31  Col  Lee  DeRemer,  Army  War  College  Seminar  Discussion,  1  February  2008. 


23 


32  Center  for  Strategic  and  International  Studies  (CSIS),  “Beyond  Goldwater-Nichols:  U.S. 
Government  and  Defense  Reform  for  a  New  Strategic  Era.  Phase  2  Report,”  March  2004,  19. 

33  Ibid.,  146. 

34  COL  Harold  Greene,  Director  of  Material,  G8,  HQDA,  interview  by  author,  27  January 
2008. 

35  Lynne  C.  Thompson  and  Sheila  R.  Ronis,  U.S.  Defense  Industrial  Base:  National 
Security  Implications  of  a  Globalized  World  (Washington,  D.C.:  National  Defense  University 
Press,  2  June  2005),  33. 

36  Greene,  27  January  2008. 

37  AR  71-9. 

38  Greene,  27  January  2008. 

39  Greene,  27  January  2008. 

40  U.S.  Department  of  Defense,  CENTCOM,  7  June  2007,  “Introduction  of  New  Information 
Technology  (IT)  Into  the  CENTCOM  AOR,”  official  correspondence,  email  message  to  author,  8 
Jan  2008.  Hereafter  referred  to  as  CENTCOM  IT  Policy. 

41  Richard  Cody,  Vice  Chief  of  Staff,  Army.  “Interim  guidance  on  the  Deployment  of 
Knowledge  Management  and  Collaboration  Capabilities  in  the  Tactical  Environment  Proposed 
SIPR  message,”  24  July  2006,  email  attachment  to  author,  8  Jan  2008. 

42  Marshall  Reed,  “Trip  Report  -  United  States  Central  Command  (USCENTCOM)  Joint 
Information  Management  Board  (JIMB)  Conference,  CENTCOM  Forward  Headquarters,  Qatar, 
5-7  February  2007,”  Ft.  Lewis,  10  February  2007. 

43  U.S.  Office  of  the  Under  Secretary  of  Defense  for  Acquisition,  Technology  and  Logistics, 
“Node  Management  And  Deployable  Depot  (NOMADD)  -  Implements  a  Deployable  End-to-End 
(‘Factory-to-Foxhole’)  Distribution  System,  Including  Asset  Visibility  Using  Radio-Frequency 
Identification,"  available  from  http://www.acq.osd.mil/jctd/descript.htm;  Internet;  accessed  28 
Feb  08. 

44  CENTCOM  IT  Policy. 

45  U.S.  Department  of  Defense,  2006  Quadrennial  Defense  Review  (Washington,  D.C.:  U.S. 
Department  of  Defense,  6  Feb  2006),  Sec1:vi. 

46  LTC  James  Mattis  and  COL  Frank  Hoffman,  “Future  Warfare:  The  Rise  of  Hybrid  Wars,” 
Proceedings:  U.S.  Naval  Institute  131,  November  2005,  2. 

47  Krepinevich,  1 1 . 

48  Helen  Greiner,  “iRobot,”  lecture,  U.S.  Army  War  College,  Carlisle  Barracks,  13  February 
2008,  cited  with  permission  of  Helen  Greiner. 


24 


49 


NCOE-JIC. 


25 


26 


